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REMARKS 

A review of the claims indicates that: 

A) Claims 1, 14 and 21 are currently amended. 

B) Claims 6-8, 13, 15-20 and 22-29 remain in their original form. 

C) Claims 2-5, 9-12 and 22 are cancelled. 

D) New Claim 30 depends from Claim 1 . 

In view of the following remarks, Applicant respectfully requests 
reconsideration of the rejected claims and withdrawal of the rejections. 
Examiner Interview 

The Applicant would like to thank the Examiner for taking the time to 
interview this case. In particular, the Applicant would like to invite the Examiner 
to call the undersigned representative of the Applicant upon receipt of this 
Response, so that additional discussion can take place. 

New Claim 30 

The Applicant would like to point to new Claim 30, which depends from 
Claim 1 . In the Interview, the Examiner expressed the opinion that such a claim 
was very likely allowable. 

Claim Amendments and Cancellations 

The Applicant has made a number of claim amendments and cancellations. 
These changes are not a reflection of an opinion of the allowability of any claim, 
or of the content, disclosure and/or teaching of the prior art of record. Instead, the 
changes reflect a desire on the part of the Applicant to advance the prosecution of 
this application, to reduce the expense and time of the pending period, and to 
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thereby expedite prosecution. The Applicant retains the right to file claims having 
the same or similar scope at a future date. 
Section 103 Rejections 

Claims 1, 2, 4, 5, 9-15, 20, 21 and 26 were rejected under 35 U.S.C. 

§ 103(a) as being unpatentable over U.S. Patent No. 20020013910, hereinafter 
"Edery" in view of U.S. Pat. No. 5,960,170 hereinafter "Chen." In response, the 
Applicant respectfully traverses the rejection. 



Claim 1 recites a processor-readable medium comprising processor- 
executable instmctions for: 

• parsing an input file to recognize a file format of the input file, 
wherein the parsing repeatedly parses once with each of a 
plurality of component parsers contained within a compound 
parser, wherein each of the plurality of component parsers is 
configured for recognition of a specific file format by which an 
input file is configured, wherein the compound parser is 
extensible, and wherein extending the compound parser 
comprises adding an additional component parser; 

• checking contents of the input file, according to the recognized file 
format, to determine whether executable code exists within the input 
file, wherein the checking comprises detecting executable code 
because its location within the input file is inconsistent with the 
recognized file format; 

• continuing to parse the input file with all remaining component 
parsers after at least one component parser recognizes the file format 
of the input file; and 

• sending a status in response to results of said checking, wherein 
sending a status comprises further instructions for: 

• sending a file-has-no-code status when the file format of the 
input file was recognized and no executable code was found; 

• sending a file-has-code status when executable code was found; 

• sending a don't-know status when the file format of the input 
file was not recognized. 
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Claim 1 recites , "wherein the parsing repeatedly parses once with each of a 
plurality of component parsers contained within a compound parser". The 
Applicant respectfully submits that the prior art of record does not teach such a 
parsing method, in which a compound parser comprising component parsers is 
utilized. 

In a related matter prior to amendment of Claim 1, the Patent Office 
pointed to Chen at column 7, lines 20-25, and suggested that Chen might make 
such a teaching. 

However, as discussed in the Examiner Interview, the Chen reference 
teaches that a "plurality of virus detection objects" (emphasis added) are produced 
by the server and sent to the client. This is in contrast to the file type detection 
function recited by the Applicant's Claim 1. 

The Patent Office also points to Chen at the bottom column 7 and the top of 
column 8, wherein Chen discusses that based on "platform or file type" (column 8, 
line 2) the virus detection software could "tailored" (column 7, line 65). The 
Applicant respectfully submits that this is distinguished from Claim 1 at least 
because Chen does not teach how the file type is determined . The Applicant 
recites detail in Claim 1 as to how the file type is determined (e.g. using a 
compound parser, having plural component parsers, each component parser 
configured to recognize one specific file type). 

Claim 1 additionally recites , "sending a don't-know status when the file 
format of the input file was not recognized." The Applicant submits that Edery 
and Chen, taken singly or in combination, fail to teach or suggest a 'don't know' 
status in response to failure to recognize a file format . 
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The Patent Office points to Edery at paragraph [0088], suggesting that a 
"don't know" status is sent when a format of an input file is not recognized. The 
Applicant respectfully disagrees. 

Referring to Edery at [0088], the first two sentences (first 7 lines) discuss 
file inflation (i.e. decompressing a file). Referring to Fig. 5, the file inflator 504 is 
configured to de-compress a file. 

The third sentence, lines 7 — 1 1 of [0088], discuss that a compressed meta 
file may include nested file type information not otherwise reliably provided in an 
overall file header. In such circumstances, the file inflator 504 returns that 
information to the parser 502. 

In the fourth and final sentence in Edery's paragraph [0088], Edery 
discloses that the file inflator 504 also provides executable files to the control 
block 506, where they may be packaged with an MPC or policies. 

Therefore, the Applicant submits that a careful review of Edery's paragraph 
[0088] indicates no disclosure of "sending a don't-know status when the file 
format of the input file was not recognized". In fact, Edery does not address 
failure to recognize a file format of an input file. Accordingly, Edery does not 
address sending a "don't know" status. 

Chen is not cited for teaching "don't know" in response to a failure to 
determine a file format, and the Applicant respectfully submits that Chen fails to 
remedy the failings of Edery. 

Claim 1 additionally recites , "the compound parser is extensible, and 
wherein extending the compound parser comprises adding an additional 
component parser". The Applicant respectfiilly submits that the prior art of record 
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fails to teach or suggest such a compound parser made up of a plurality of 
component parsers. 

The Patent Office points to Chen, and suggests that Chen teaches 
extensibility at column 7 lines 20-25, wherein Chen teaches that a plurality of 
virus detection objects are produced. The Applicant respectfully submits that such 
objects are not ever collectively assembled to form a compound object. Moreover, 
they do not serve a parsing function, as recited . 

Claim 1 additionally recites , "detecting executable code because its location 
within the input file is inconsistent with the recognized file format". (See the 
Applicant's paragraph [0028] and other locations. 

The Applicant submits that Edery and Chen, taken singly or in 
combination, fail to teach or suggest that the known and/or expected organization 
of a recognized file format can be used to find executable code. 

Edery teaches file type detection (see Edery at [0086]). However, Edery is 
looking for files with executable extensions like "exe". Thus, Edery is looking for 
"whether the potential-Downloadable (likely) is or includes an executable file 
type" (first sentence in [0086]). But, Edery doesn't teach "detecting executable 
code because its location within the input file is inconsistent with the recognized 
file formaf (emphasis added). 

Chen teaches that that anti-virus information can be limited if the file type 
is known (last two lines of column 7 and top 2 lines of column 8). However, Chen 
fails to teach or suggest any specifics whereby executable code is recognized 
based on file type. Specifically, Chen fails to teach or suggest that executable 
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code is recognized based on its location within the input file, which is inconsistent 
with the file type of that input file. 

Claim 1 additionally recites , "parsing an input file to recognize a file format 
of the input file, wherein the parsing repeatedly parses with a plurality of 
component parsers contained within an extensible parser". 

The Applicant submits, inter alia, that Edery does not recognize a file's 
format using component parsers contained in an extensible parser. The Applicant 
further submits that, at most, Edery discloses components 551, 552 that are 
configured to detect///e content, not to recognize a file format. 

Referring to Fig. 5, [0086] and [0087] of the Edery reference, Edery 
discloses that a file type detector 503 determines whether a file is, or includes, an 
executable file type (see [0086] first 3 lines). Referring to Fig. 5, Edery does not 
disclose that detector 503 includes a pkirality of component parsers within an 
extensible parser, as recited by Claim 1 . The detector is configured to analyze the 
file header (see [0086] next 7 lines). Edery discloses that the headers of 
compressed files, such as zipped files, can also be examined, to determine if 
executable code and/or file types are included ([0086] next several lines). 
Additionally, the detector examines file delimiters such as ".exe" to determine if 
executable code is present. 

Accordingly, Edery discloses that the file type detector 503 detects files 
that have, or likely have, executable code ([0086], first several lines). However, 
Edery' s file type detector 503 is not configured to repeatedly parse with a plurality 
of component parsers contained within an extensible parser . The use of 
component parsers to recognize a file format is not disclosed by Edery. 
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Referring to paragraph [0092] and Fig. 5 of the Edery reference, Edery 
discloses a content detector 505, configured to provide one or more content 
analyses, such as distinguishing binary data, pattern data and other data. For 
example, the content may be analyzed for binary information ([0092] at line 6) by 
binary detector 551. Additionally, the content may be analyzed for pattern 
detection by pattern detector 552 ([0092] at line 7). 

Thus, Edery discloses a content detector that includes plural elements. 
However, a disclosure of "content analysis" does not anticipate a recitation of "File 
format recognition" . Edery performs file format recognition at 503, thereby 
showing that "content analysis" is distinct from "file format recognition." The 
Applicant has recited, "parsing an input File to recognize a file format of the input 
File, wherein the parsing the input File repeatedly parses with a plurality of 
component parsers contained within an extensible parser" (emphasis added). The 
recitation by Claim 1 of components to recognize a file format is not anticipated 
by the Edery disclosure of a content detector having two or more component parts. 
That is, the Applicant recites, "recognizing a file format" while Edeiy discloses, 
"content detection". The Applicant respectfully submits that, for at least this 
reason, that Edery does not fairly anticipate the Applicant's claim. 

Notwithstanding the above remarks, the Patent Office suggests that Edery 
discloses component parsers within an extensible parser (see Office Action mailed 
06/29/2007, page 3, rejection of Claim 4 (now incorporated by amendment into 
Claim 1)). In particular, the Patent Office points to Edery at [0086], [0087] and 
[0092] and suggests that Edery discloses component parsers contained within an 
extensible parser to recognize file format. The Applicant respectfully disagrees. 
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As noted above, Edery's content detector 505 includes components 551 and 
552. However, the content detector does not determine a data file format. Recall 
that a file format is a type of file, such as "jpeg", "PDF" and "doc". Each file 
format, such as the Microsoft Word "doc" format, has specific conventions 
regarding data storage. Instead, Edery specifically discloses that the detectors 551 
and 552 detect binary data and pattern data, respectively (see [0092]). Therefore, 
while Edery's detector 505 detects binary data and/or data patterns, it does not 
recognize file format . Instead, Edery recognizes file format at 503 (Fig. 5). 

Accordingly, the Applicant respectfully submits that, in part due to the 
proposed claim amendments, the Edery and Chen references do not fairly support 
a Section 103 rejection, and respectfully requests that the Section 103 rejection be 
removed. 

Claim 1 additionallv recites , "continuing to parse the input file with all 
remaining component parsers after at least one component parser recognizes the 
file format of the input file". As discussed in the Examiner interview, the Edery 
reference does not show or disclose such continued parsing, as recited, wherein the 
parsing is based on recognizing file formats. 

In rejecting Claims 11 and 12 (now incorporated in Claim 1) the Patent 
Office pointed to Edery at paragraphs [0092] and [0093]. 

However, a review of Edery, generally and at these locations, does not 
reveal a disclosure of the use of an extensible and compound parser organized so 
that each component parser is associated with a particular file type (e.g. a DWG 
file type). Instead, Edery discloses the use of "binary" and "pattern" "detectors" 
wherein each detector is not associated with recognition of an individual file type . 
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Accordingly, Edery does not disclose the compound parser as recited, having 
component parsers associated with individual file types. 

Without passing judgment on the allowability of Claim 1 prior to 
amendment, but in view of the claim amendments and arguments presented above, 
the Applicant respectfully submits that the Edery and Chen references do not fairly 
support a Section 103 rejection, and respectfully requests that the Section 103 
rejection be removed. 

Claims 6-8 and 13 depend from Claim 1 and are allowable due to their 
dependence from an allowable base claim. These claims are also allowable for 
their own recited features that, in combination with those recited in Claim 1, are 
not taught and not suggested in references of record, either singly or in 
combination with one another. 



Claim 14 recites a method of detecting code-free files, comprising: 

• identifying a new file format, wherein ability to recognize the 
new file format is functionality to be extended to a compound 
parser; 

• configuring a new component parser according to the new file 
format, wherein the new component parser is configured to 
recognize files of the new format and also to recognize 
executable code in files of the new format by locating executable 
code that is inconsistent with the new file format; and 

• extending functionality of the compound parser by adding the 
new component parser to the compound parser; 

• wherein the compound parser, having extended functionality, is 
configured to operate to parse an input file by: 

• parsing the input file with the compound parser, wherein the 
compound parser is configured to include a plurality of 
component parsers, wherein each component parser is 
configured to recognize a specific data file format; 

• analyzing contents of the input file according to the recognized 
specific file format, where available, to determine if the input file 
contains executable code; and 
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• sending a status in response to results of said analyzing. 

Claim 14 has been amended in a manner consistent with the disclosure at 
the Applicant's Fig. 6 and other locations. As discussed in the Examiner's 
Interview , this subject matter is not taught or suggested by the prior art of record. 
Accordingly, the Applicant respectfully submits that he Section 103 rejection is 



Claim 14 is also allowable for at least the reasons Claim 1 is allowable, and 
the remarks and arguments from above are incorporated herein by reference. 

Claims 15 — 20 depend from Claim 14 and are allowable due to their 
dependence from an allowable base claim. These claims are also allowable for 
their own recited features that, in combination with those recited in Claim 14, are 
not shown and not disclosed in references of record, either singly or in 
combination with one another. 



Claim 21 recites an apparatus for detecting code-free files, comprising: 

• a compound parser configured to repeatedly parse an input file, 
wherein each component parser within the compound parser is 
configured to recognize executable code within a specific file format 
selected from among a group of data file formats; and 

• a controller to examine success of each of the component parsers 
to recognize the specific file format for which it was configured 
to recognize and to find executable code within the input file, 
wherein the controller is configured to send a status in response to 
results of said checking, wherein sending a status comprises: 

• sending a file-has-no-code status when the file format of the 
input file was recognized and no executable code was found; 

• sending a file-has-code status when executable code was found; 

• sending a don't-know status when the file format of the input 
file was not recognized. 
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Claim 21 recites aspects also recited by Claims 1 and 14, and is allowable 
for at least the reasons discussed above with those claims. Accordingly, the 
remarks and arguments from above are incorporated herein. 

In particular, Claim 21 recites, "sending a don't-know status when the file 
format of the input file was not recognized". The Applicant respectfully submits 
that Edery does not disclose a "don't know" status indicating that an input file 
format was not recognized. 

The Patent Office points to Edery at paragraph [0088], suggesting that a 
"don't know" status is sent when a format of an input file is not recognized. The 
Applicant respectfully disagrees. 

Referring to Edery at [0088], the first two sentences (first 7 lines) discuss 
file inflation (i.e. decompressing a file). Referring to Fig. 5, the file inflator 504 is 
configured to de-compress a file. 

The third sentence, lines 7 — 1 1 of [0088], discuss that a compressed meta 
file may include nested file type information not otherwise reliably provided in an 
overall file header. In such circumstances, the file inflator 504 returns that 
information to the parser 502. 

In the fourth and final sentence in Edery's paragraph [0088], Edery 
discloses that the file inflator 504 also provides executable files to the control 
block 506, where they may be packaged with an MPC or policies. 

Therefore, the Applicant submits that a careful review of Edery's paragraph 
[0088] indicates no disclosure of "sending a don't-know status when the file 
format of the input file was not recognized". In fact, Edery does not address 
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failure to recognize a file format of an input file. Accordingly, Edery does not 
address sending a "don't know" status. 

In view of the above, the Applicant respectfully requests that the Section 
102 rejection be removed. 

Claims 23 — 29 depend from Claim 21 and are allowable due to their 
dependence from an allowable base claim. These claims are also allowable for 
their own recited features that, in combination with those recited in Claim 21, are 
not shown and not disclosed in references of record, either singly or in 
combination with one another. 

Conclusion 

The Applicant submits that the amended claims are in an allowable 
condition, and requests that the Examiner call the undersigned representative, so 
that any remaining issues can be resolved. 

Respectfully Submitted, 

Dated: 06 October 2008 By: /David S. Thompson/ 

David S. Thompson 
Reg. No. 37,954 
Attorney for Applicant 

LEE & HAYES PLLC 
Suite 500 

421 W. Riverside Avenue 
Spokane, Washington 99201 

Telephone: 509-324-9256 x235 
Facsimile: (509) 323-8979 
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